<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Section 16.2.&nbsp; Socket Descriptors</title>
<link rel="STYLESHEET" type="text/css" href="images/style.css">
<link rel="STYLESHEET" type="text/css" href="images/docsafari.css">
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/team.gif" width="60" height="17" border="0" align="absmiddle"  alt="Team BBL"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href=ch16lev1sec1.html><img src="images/prev.gif" width="60" height="17" border="0" align="absmiddle" alt="Previous Page"></a>
<a href=ch16lev1sec3.html><img src="images/next.gif" width="60" height="17" border="0" align="absmiddle" alt="Next Page"></a>
</div></td></tr></table>
<br><table width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td valign="top"><a name="ch16lev1sec2"></a>
<h3 class="docSection1Title" id="454331-907">16.2. Socket Descriptors</h3>
<p class="docText"><a name="idd1e119378"></a><a name="idd1e119383"></a><a name="idd1e119388"></a><a name="idd1e119393"></a><a name="idd1e119398"></a><a name="idd1e119403"></a><a name="idd1e119408"></a><a name="idd1e119413"></a><a name="idd1e119420"></a>A socket is an abstraction of a communication endpoint. Just as they would use file descriptors to access a file, applications use socket descriptors to access sockets. Socket descriptors are implemented as file descriptors in the UNIX System. Indeed, many of the functions that deal with file descriptors, such as <tt>read</tt> and <tt>write</tt>, will work with a socket descriptor.</P>
<p class="docText">To create a socket, we call the <tt>socket</tt> function.</P>
<a name="inta329"></a><p><table cellspacing="0" class="allBorders" border="1" RULES="none" cellpadding="5"><colgroup><col width="500"></colgroup><thead></thead><TR><TD class="docTableCell" align="left" valign="top"><p class="docText">
<pre>
#include &lt;sys/socket.h&gt;

int socket(int <span class="docEmphItalicAlt">domain</span>, int <span class="docEmphItalicAlt">type</span>, int <span class="docEmphItalicAlt">protocol</span>);
</pre><BR>

</p></TD></TR><TR><td class="docTableCell" align="right" valign="top"><p class="docText">Returns: file (socket) descriptor if OK, 1 on error</P></td></TR></table></P><BR>
<p class="docText">The <span class="docEmphasis">domain</span> argument determines the nature of the communication, including the address format (described in more detail in the next section). <a class="docLink" href="#ch16fig01">Figure 16.1</a> summarizes the domains specified by POSIX.1. The constants start with <tt>AF_</tt> (for <span class="docEmphasis">address family</span>) because each domain has its own format for representing an address.</p>
<a name="ch16fig01"></a><P><table cellspacing="0" class="allBorders" border="1" RULES="groups" cellpadding="5"><caption><H5 class="docTableTitle">Figure 16.1. Socket communication domains</h5></caption><colgroup><col width="100"><col width="200"></colgroup><thead><TR><th class="rightBorder bottomBorder thead" scope="col" align="center" valign="top"><p class="docText"><span class="docEmphRoman">Domain</span></P></th><th class="bottomBorder thead" scope="col" align="center" valign="top"><p class="docText"><span class="docEmphRoman">Description</span></p></th></tr></thead><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>AF_INET</tt></P></td><TD class="docTableCell" align="left" valign="top"><p class="docText">IPv4 Internet domain</p></TD></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>AF_INET6</tt></p></td><td class="docTableCell" align="left" valign="top"><p class="docText">IPv6 Internet domain</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>AF_UNIX</tt></p></td><td class="docTableCell" align="left" valign="top"><p class="docText">UNIX domain</p></td></tr><TR><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>AF_UNSPEC</tt></p></TD><TD class="docTableCell" align="left" valign="top"><p class="docText">unspecified</P></td></TR></table></P><BR>
<p class="docText">We discuss the UNIX domain in <a class="docLink" href="ch17lev1sec3.html#ch17lev1sec3">Section 17.3</a>. Most systems define the <tt>AF_LOCAL</tt> domain also, which is an alias for <tt>AF_UNIX</tt>. The <tt>AF_UNSPEC</tt> domain is a wildcard that represents &quot;any&quot; domain. Historically, some platforms provide support for additional network protocols, such as <tt>AF_IPX</tt> for the NetWare protocol family, but domain constants for these protocols are not defined by the POSIX.1 standard.</p>
<p class="docText">The <span class="docEmphasis">type</span> argument determines the type of the socket, which further determines the communication characteristics. The socket types defined by POSIX.1 are summarized in <a class="docLink" href="#ch16fig02">Figure 16.2</a>, but implementations are free to add support for additional types.</P>
<a name="ch16fig02"></a><p><table cellspacing="0" class="allBorders" border="1" RULES="groups" cellpadding="5"><caption><H5 class="docTableTitle">Figure 16.2. Socket types</H5></caption><colgroup><col width="100"><col width="400"></colgroup><thead><TR><th class="rightBorder bottomBorder thead" scope="col" align="center" valign="top"><p class="docText"><span class="docEmphRoman">Type</span></p></th><th class="bottomBorder thead" scope="col" align="center" valign="top"><p class="docText"><span class="docEmphRoman">Description</span></P></th></TR></thead><tr><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>SOCK_DGRAM</tt></P></td><td class="docTableCell" align="left" valign="top"><p class="docText">fixed-length, connectionless, unreliable messages</p></td></TR><tr><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>SOCK_RAW</tt></p></TD><td class="docTableCell" align="left" valign="top"><p class="docText">datagram interface to IP (optional in POSIX.1)</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>SOCK_SEQPACKET</tt></p></td><td class="docTableCell" align="left" valign="top"><p class="docText">fixed-length, sequenced, reliable, connection-oriented messages</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>SOCK_STREAM</tt></p></td><td class="docTableCell" align="left" valign="top"><p class="docText">sequenced, reliable, bidirectional, connection-oriented byte streams</P></TD></tr></table></P><BR>
<p class="docText">The <span class="docEmphasis">protocol</span> argument is usually zero, to select the default protocol for the given domain and socket type. When multiple protocols are supported for the same domain <a name="idd1e119686"></a><a name="idd1e119691"></a><a name="idd1e119696"></a><a name="idd1e119701"></a><a name="idd1e119706"></a><a name="idd1e119711"></a><a name="idd1e119716"></a>and socket type, we can use the <span class="docEmphasis">protocol</span> argument to select a particular protocol. The default protocol for a <tt>SOCK_STREAM</tt> socket in the <tt>AF_INET</tt> communication domain is TCP (Transmission Control Protocol). The default protocol for a <tt>SOCK_DGRAM</tt> socket in the <tt>AF_INET</tt> communication domain is UDP (User Datagram Protocol).</P>
<p class="docText">With a datagram (<tt>SOCK_DGRAM</tt>) interface, no logical connection needs to exist between peers for them to communicate. All you need to do is send a message addressed to the socket being used by the peer process.</p>
<p class="docText">A datagram, therefore, provides a connectionless service. A byte stream (<tt>SOCK_STREAM</tt>), on the other hand, requires that, before you can exchange data, you set up a logical connection between your socket and the socket belonging to the peer you want to communicate with.</P>
<p class="docText">A datagram is a self-contained message. Sending a datagram is analogous to mailing someone a letter. You can mail many letters, but you can't guarantee the order of delivery, and some might get lost along the way. Each letter contains the address of the recipient, making the letter independent from all the others. Each letter can even go to different recipients.</P>
<p class="docText">In contrast, using a connection-oriented protocol for communicating with a peer is like making a phone call. First, you need to establish a connection by placing a phone call, but after the connection is in place, you can communicate bidirectionally with each other. The connection is a peer-to-peer communication channel over which you talk. Your words contain no addressing information, as a point-to-point virtual connection exists between both ends of the call, and the connection itself implies a particular source and destination.</P>
<p class="docText">With a <tt>SOCK_STREAM</tt> socket, applications are unaware of message boundaries, since the socket provides a byte stream service. This means that when we read data from a socket, it might not return the same number of bytes written by the process sending us data. We will eventually get everything sent to us, but it might take several function calls.</p>
<p class="docText">A <tt>SOCK_SEQPACKET</tt> socket is just like a <tt>SOCK_STREAM</tt> socket except that we get a message-based service instead of a byte-stream service. This means that the amount of data received from a <tt>SOCK_SEQPACKET</tt> socket is the same amount as was written. The Stream Control Transmission Protocol (SCTP) provides a sequential packet service in the Internet domain.</P>
<p class="docText">A <tt>SOCK_RAW</tt> socket provides a datagram interface directly to the underlying network layer (which means IP in the Internet domain). Applications are responsible for building their own protocol headers when using this interface, because the transport protocols (TCP and UDP, for example) are bypassed. Superuser privileges are required to create a raw socket to prevent malicious applications from creating packets that might bypass established security mechanisms.</p>
<p class="docText">Calling <tt>socket</tt> is similar to calling <tt>open</tt>. In both cases, you get a file descriptor that can be used for I/O. When you are done using the file descriptor, you call <tt>close</tt> to relinquish access to the file or socket and free up the file descriptor for reuse.</P>
<p class="docText">Although a socket descriptor is actually a file descriptor, you can't use a socket descriptor with every function that accepts a file descriptor argument. <a class="docLink" href="#ch16fig03">Figure 16.3</a> summarizes most of the functions we've described so far that are used with file <a name="idd1e119799"></a><a name="idd1e119804"></a><a name="idd1e119809"></a><a name="idd1e119814"></a><a name="idd1e119819"></a><a name="idd1e119824"></a><a name="idd1e119829"></a><a name="idd1e119834"></a><a name="idd1e119839"></a><a name="idd1e119844"></a><a name="idd1e119849"></a><a name="idd1e119854"></a><a name="idd1e119859"></a><a name="idd1e119864"></a><a name="idd1e119869"></a><a name="idd1e119874"></a><a name="idd1e119879"></a><a name="idd1e119884"></a><a name="idd1e119889"></a><a name="idd1e119894"></a><a name="idd1e119899"></a><a name="idd1e119904"></a><a name="idd1e119909"></a><a name="idd1e119914"></a><a name="idd1e119919"></a><a name="idd1e119924"></a><a name="idd1e119929"></a><a name="idd1e119934"></a><a name="idd1e119939"></a><a name="idd1e119944"></a><a name="idd1e119949"></a><a name="idd1e119954"></a><a name="idd1e119959"></a><a name="idd1e119964"></a><a name="idd1e119969"></a><a name="idd1e119976"></a><a name="idd1e119981"></a><a name="idd1e119986"></a><a name="idd1e119991"></a><a name="idd1e119994"></a><a name="idd1e119999"></a><a name="idd1e120002"></a><a name="idd1e120007"></a>descriptors and describes how they behave when used with a socket descriptor. Unspecified and implementation-defined behavior usually means that the function doesn't work with socket descriptors. For example, <tt>lseek</tt> doesn't work with sockets, since sockets don't support the concept of a file offset.</P>
<a name="ch16fig03"></a><P><table cellspacing="0" class="allBorders" border="1" RULES="groups" cellpadding="5"><caption><h5 class="docTableTitle">Figure 16.3. How file descriptor functions act with sockets</H5></caption><colgroup><col width="200"><col width="300"></colgroup><thead><TR><th class="rightBorder bottomBorder thead" scope="col" align="center" valign="top"><p class="docText"><span class="docEmphRoman">Function</span></p></th><th class="bottomBorder thead" scope="col" align="center" valign="top"><p class="docText"><span class="docEmphRoman">Behavior with socket</span></P></th></TR></thead><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>close</tt> (<a class="docLink" href="ch03lev1sec3.html#ch03lev1sec3">Section 3.3</a>)</p></td><TD class="docTableCell" align="left" valign="top"><p class="docText">deallocates the socket</p></TD></tr><TR><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>dup</tt>, <tt>dup2</tt> (<a class="docLink" href="ch03lev1sec12.html#ch03lev1sec12">Section 3.12</a>)</p></td><td class="docTableCell" align="left" valign="top"><p class="docText">duplicates the file descriptor as normal</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>fchdir</tt> (<a class="docLink" href="ch04lev1sec22.html#ch04lev1sec22">Section 4.22</a>)</p></td><td class="docTableCell" align="left" valign="top"><p class="docText">fails with <tt>errno</tt> set to <tt>ENOTDIR</tt>
</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>fchmod</tt> (<a class="docLink" href="ch04lev1sec9.html#ch04lev1sec9">Section 4.9</a>)</P></TD><td class="docTableCell" align="left" valign="top"><p class="docText">unspecified</P></TD></TR><tr><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>fchown</tt> (<a class="docLink" href="ch04lev1sec11.html#ch04lev1sec11">Section 4.11</a>)</P></TD><td class="docTableCell" align="left" valign="top"><p class="docText">implementation defined</P></td></TR><TR><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>fcntl</tt> (<a class="docLink" href="ch03lev1sec14.html#ch03lev1sec14">Section 3.14</a>)</p></TD><TD class="docTableCell" align="left" valign="top"><p class="docText">some commands supported, including <tt>F_DUPFD</tt>, <tt>F_GETFD</tt>, <tt>F_GETFL</tt>, <tt>F_GETOWN</tt>, <tt>F_SETFD</tt>, <tt>F_SETFL</tt>, and <tt>F_SETOWN</tt>
</p></TD></TR><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>fdatasync</tt>, <tt>fsync</tt> (<a class="docLink" href="ch03lev1sec13.html#ch03lev1sec13">Section 3.13</a>)</p></td><TD class="docTableCell" align="left" valign="top"><p class="docText">implementation defined</p></TD></tr><TR><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>fstat</tt> (<a class="docLink" href="ch04lev1sec2.html#ch04lev1sec2">Section 4.2</a>)</p></td><td class="docTableCell" align="left" valign="top"><p class="docText">some <tt>stat</tt> structure members supported, but how left up to the implementation</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>ftruncate</tt> (<a class="docLink" href="ch04lev1sec13.html#ch04lev1sec13">Section 4.13</a>)</p></td><td class="docTableCell" align="left" valign="top"><p class="docText">unspecified</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>getmsg</tt>, <tt>getpmsg</tt> (<a class="docLink" href="ch14lev1sec4.html#ch14lev1sec4">Section 14.4</a>)</P></TD><td class="docTableCell" align="left" valign="top"><p class="docText">works if sockets are implemented with STREAMS (i.e., on Solaris)</P></TD></TR><tr><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>ioctl</tt> (<a class="docLink" href="ch03lev1sec15.html#ch03lev1sec15">Section 3.15</a>)</P></TD><td class="docTableCell" align="left" valign="top"><p class="docText">some commands work, depending on underlying device driver</P></td></TR><TR><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>lseek</tt> (<a class="docLink" href="ch03lev1sec6.html#ch03lev1sec6">Section 3.6</a>)</p></TD><TD class="docTableCell" align="left" valign="top"><p class="docText">implementation defined (usually fails with <tt>errno</tt> set to <tt>ESPIPE</tt>)</p></TD></TR><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>mmap</tt> (<a class="docLink" href="ch14lev1sec9.html#ch14lev1sec9">Section 14.9</a>)</p></td><TD class="docTableCell" align="left" valign="top"><p class="docText">unspecified</p></TD></tr><TR><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>poll</tt> (<a class="docLink" href="ch14lev1sec5.html#ch14lev2sec15">Section 14.5.2</a>)</p></td><td class="docTableCell" align="left" valign="top"><p class="docText">works as expected</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>putmsg</tt>, <tt>putpmsg</tt> (<a class="docLink" href="ch14lev1sec4.html#ch14lev1sec4">Section 14.4</a>)</p></td><td class="docTableCell" align="left" valign="top"><p class="docText">works if sockets are implemented with STREAMS (i.e., on Solaris)</p></td></tr><tr><td class="rightBorder" align="left" valign="top"><p class="docText"><tt>read</tt> (<a class="docLink" href="ch03lev1sec7.html#ch03lev1sec7">Section 3.7</a>) and <tt>readv</tt> (<a class="docLink" href="ch14lev1sec7.html#ch14lev1sec7">Section 14.7</a>)</P></TD><td class="docTableCell" align="left" valign="top"><p class="docText">equivalent to <tt>recv</tt> (<a class="docLink" href="ch16lev1sec5.html#ch16lev1sec5">Section 16.5</a>) without any flags</P></TD></TR><tr><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>select</tt> (<a class="docLink" href="ch14lev1sec5.html#ch14lev2sec14">Section 14.5.1</a>)</P></TD><td class="docTableCell" align="left" valign="top"><p class="docText">works as expected</P></td></TR><TR><TD class="rightBorder" align="left" valign="top"><p class="docText"><tt>write</tt> (<a class="docLink" href="ch03lev1sec8.html#ch03lev1sec8">Section 3.8</a>) and <tt>writev</tt> (<a class="docLink" href="ch14lev1sec7.html#ch14lev1sec7">Section 14.7</a>)</p></TD><TD class="docTableCell" align="left" valign="top"><p class="docText">equivalent to <tt>send</tt> (<a class="docLink" href="ch16lev1sec5.html#ch16lev1sec5">Section 16.5</a>) without any flags</p></TD></TR></table></p><br>
<p class="docText">Communication on a socket is bidirectional. We can disable I/O on a socket with the <tt>shutdown</tt> function.</p>
<a name="inta311"></a><p><table cellspacing="0" class="allBorders" border="1" RULES="none" cellpadding="5"><colgroup><col width="500"></colgroup><thead></thead><TR><td class="docTableCell" align="left" valign="top"><p class="docText">
<pre>
#include &lt;sys/socket.h&gt;

int shutdown (int <span class="docEmphItalicAlt">sockfd</span>, int <span class="docEmphItalicAlt">how</span>);
</pre><BR>

</p></TD></tr><tr><td class="docTableCell" align="right" valign="top"><p class="docText">Returns: 0 if OK, 1 on error</p></td></tr></table></p><br>
<p class="docText">If <span class="docEmphasis">how</span> is <tt>SHUT_RD</tt>, then reading from the socket is disabled. If <span class="docEmphasis">how</span> is <tt>SHUT_WR</tt>, then we can't use the socket for transmitting data. We can use <tt>SHUT_RDWR</tt> to disable both data transmission and reception.</p>
<p class="docText">Given that we can <tt>close</tt> a socket, why is <tt>shutdown</tt> needed? There are several reasons. First, <tt>close</tt> will deallocate the network endpoint only when the last active reference is closed. This means that if we duplicate the socket (with <tt>dup</tt>, for example), <a name="idd1e120503"></a><a name="idd1e120506"></a><a name="idd1e120509"></a><a name="idd1e120514"></a><a name="idd1e120519"></a><a name="idd1e120522"></a><a name="idd1e120525"></a><a name="idd1e120528"></a>the socket won't be deallocated until we close the last file descriptor referring to it. The <tt>shutdown</tt> function allows us to deactivate a socket independently of the number of active file descriptors referencing it. Second, it is sometimes convenient to shut a socket down in one direction only. For example, we can shut a socket down for writing if we want the process we are communicating with to be able to determine when we are done transmitting data, while still allowing us to use the socket to receive data sent to us by the process.</p>

<ul></ul></td></tr></table>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/team.gif" width="60" height="17" border="0" align="absmiddle"  alt="Team BBL"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href=ch16lev1sec1.html><img src="images/prev.gif" width="60" height="17" border="0" align="absmiddle" alt="Previous Page"></a>
<a href=ch16lev1sec3.html><img src="images/next.gif" width="60" height="17" border="0" align="absmiddle" alt="Next Page"></a>
</div></td></tr></table>
</body></html><br>
<table width="100%" cellspacing="0" cellpadding="0"
style="margin-top: 0pt; border-collapse: collapse;"> 
<tr> <td align="right" style="background-color=white; border-top: 1px solid gray;"> 
<a href="http://www.zipghost.com/" target="_blank" style="font-family: Tahoma, Verdana;
 font-size: 11px; text-decoration: none;">The CHM file was converted to HTM by Trial version of <b>ChmD<!--255-->ecompiler</b>.</a>
</TD>
</TR><tr>
<td align="right" style="background-color=white; "> 
<a href="http://www.etextwizard.com/download/cd/cdsetup.exe" target="_blank" style="font-family: Tahoma, Verdana;
 font-size: 11px; text-decoration: none;">Download <b>ChmDec<!--255-->ompiler</b> at: http://www.zipghost.com</a>
</TD></tr></table>
